by James W. Truher, MIPS ABI Technical Services Manager
The MIPS® ABI Group tries very hard to have as many features as possible supported in our Conformance Guide, but unfortunately, we can not supply all the features that exist on all our vendor platforms. This article is intended to help ISVs understand alternatives for getting the most out of a port to the MIPS ABI by taking advantage of features that are specific to a particular platform without having to produce completely separate ports for each system.
Although the MIPS ABI is a cooperative group, each company maintains a set of unique features that are not consistently implemented across all the platforms of the MIPS ABI. This inconsistency can occasionally create technical difficulties when porting specific products to the MIPS ABI. In an effort to work through such technical issues, the MIPS ABI Technical Committee has now established a process allowing developers to simplify their porting efforts to MIPS ABI hardware platforms without using 100 percent MIPS ABI-compliant code. We call this a process port, and it enables ISVs requiring platform-specific object code to complete their ABI ports by taking advantage of most of our binary compatibility. A process port can benefit ISVs that do not currently support the MIPS ABI environment by helping them build application libraries as MIPS binaries-they use only one binary for all the platforms of the MIPS ABI, which reduces their porting costs and gives them access to a global market.
Many applications, especially database applications, include libraries for vertical market application development. If these libraries are MIPS ABI binary libraries, applications using these libraries can be created as MIPS ABI applications even if the database server is a non-ABI binary. As long as the libraries that are being used and compiled in by the applications are ABI compliant, the actual database server need not be. The applications built with ABI-compliant libraries will be ABI-compliant.
Occasionally, it is not possible to create a MIPS ABI application because the application requires some platform dependent information. One example of this might be an application that requires information supplied by the UNIX® kernel. The MIPS ABI has no conformance guidelines for kernel modules so applications that require this would normally fall outside of the usual definition of a MIPS ABI binary. Careful construction of this module could be done so that an interface library could retrieve data from the kernel routines. This interface library could be an ABI library much the same as above. By segregating all non-ABI calls and routines in separate modules, it is possible to create an ABI binary that takes advantage of non-ABI features. Each platform of the ABI would need to have individual kernel modules, but all other application and libraries could easily be ABI-compliant.
Outlined above are two different ways to build MIPS ABI binaries. In the case of an application that uses ABI interface libraries supplied by an ISV, a completely ABI-compliant application is created. In the case of an application that has platform-specific code, the application is not ABI-compliant but a large proportion of objects are ABI-compliant.
The benefits of creating an application with this environment are two-fold:
When fixes are made, a single fix applies to multiple platforms. It is not necessary to build the libraries for each MIPS ABI platform, because one library works on all platforms.
This allows the VAR/ISV to have better coverage of the ABI because one application will run regardless of the platform.
We encourage ISVs with applications that require system calls or libraries that currently fall outside of the MIPS ABI specification to evaluate a MIPS ABI process port. If you have questions about this process, contact Jim Truher, the MIPS ABI Services Manager, at jtruher@engr.sgi.com, or see the MIPS ABI Web site.
We welcome feedback and comments at
devprogram@sgi.com.